Subject: appnIsIn*AdjCpName and appnIsIn*AdjTgNum objects

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Fri, 20 Sep 96 08:34:15 EDT

Jim Cobban writes:

>In message "appnIsIn*AdjCpName and appnIsIn*AdjTgNum objects",
>Bob Moore writes:
>
>..
>>Here's a picture of the problematic configuration:
>>
>> node(PLU)      NNa           NNb           NNc        node(SLU)
>>
>>                  <******RTP connection*****>
>>    <----TG1----><----TG2----><----TG3----><----TG4---->
>..
>>Proposed solution:  modify the objects in the MIB so that NNa can (1)
>>indicate that in the SLU direction the next session stage is an RTP
>>connection, and (2) return the NetId.CpName of the other RTP endpoint
>>(NNc in this case).
>>
>>Changes:
>>
>>1.  Update the descriptions for appnIsInPsAdjCpName appnIsInSsAdjCpName:
>>
>>  Now: "The primary <secondary>stage adjacent CP name of this session."
>>
>>  Proposal:   "The primary <secondary>stage adjacent CP name of this
>>              session.  If the session stage traverses an RTP
>>              connection, the CP name of the remote RTP endpoint is
>>              returned."
>>
>>2.  Update the syntaxes and descriptions for appnIsInPsAdjTgNum
>>   appnIsInSsAdjTgNum:
>>
>>  Now:  SYNTAX INTEGER (0..255)
>>        "The primary <secondary>stage adjacent transmission group (TG)
>>        number associated with this session."
>>
>>  Proposal:   SYNTAX INTEGER (0..300)
>>              "The primary <secondary>stage adjacent transmission group
>>              (TG) number associated with this session.  If the session
>>              stage traverses an RTP connection, the value 256 is
>>              returned."
>
>There is certainly nothing new with defining special magic TG numbers, the
>architecture is full of them.  However I am uncomfortable with extending the
>range.  Furthermore this proposal provides only the ability to follow the
>session route.  It does not contribute to diagnosing session problems which
>originate in the RTP pipe.
>
>Instead of merely signalling that the stage is carried over RTP, I suggest
>that the MIB identify the specific RTP pipe, by NCE and TC
>identifiers, which the session stage follows.  This has been done in the APPC
>MIB, in fields appcActSessRtpNceId and appcActSessRtpTcid, so adding the
>following four fields would permit using the same diagnostic procedures for
>both end-point and ISR sessions.
>
>appnIsInPsRtpNceId OBJECT-TYPE
>      SYNTAX OCTET STRING (SIZE (0..8))
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "The HPR Network Connection Endpoint of the primary session stage."
>
>      ::= { appnIsInEntry ? }
>
>appnIsInPsRtpTcid OBJECT-TYPE
>      SYNTAX OCTET STRING (SIZE (0|8))
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "The Reliable Transport Protocol (RTP) transport onnection
>	  identifier (TCID) of the primary session stage."
>
>      ::= { appnIsInEntry ? }
>
>appnIsInSsRtpNceId OBJECT-TYPE
>      SYNTAX OCTET STRING (SIZE (0..8))
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "The HPR Network Connection Endpoint of the secondary session stage."
>
>      ::= { appnIsInEntry ? }
>
>appnIsInSsRtpTcid OBJECT-TYPE
>      SYNTAX OCTET STRING (SIZE (0|8))
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "The Reliable Transport Protocol (RTP) transport onnection
>	  identifier (TCID) of the secondary session stage."
>
>      ::= { appnIsInEntry ? }
>
>There is some risk in having a value for appnIsInXsAdjTgNum which does not
>map to a valid TG in the topology database.  If the TCID value is supplied
>then appnIsInXsAdjTgNum could be set to the actual TG number of the hop to
>appnIsInXsAdjCpName, which is carried in the RSCV in the BIND.  This value is
>no longer meaningful after a path switch, but then to find out what the
>actual route is at the moment, you could now look at the RTP table in the HPR
>MIB.

The information Jim wants is already in the MIB, in a different way.  There
are two objects, appnIsInRtpNceId and appnIsInRtpTcid, that return these
values for whichever session stage is using an RTP connection.  How does a
manager know whether this is the primary or secondary session stage?  By
seeing which direction has a TG number of 256.  I suppose we need some words
in the MIB saying that if neither session stage uses an RTP connection, then
these two objects return no meaningful information.

Rather than guaranteeing that we'll always have at least two objects that
return no meaningful information, I think we should go with my proposal
here rather than with Jim's.

Bob Moore, IBM Network Management Architecture